Robust Sector ID Scheme for Tracking Dead Sectors to Automate Search and Copydown

ABSTRACT

A brownout tolerant EEPROM emulator ( 18 ) manages memory operations at a volatile memory ( 20 ) and non-volatile memory ( 24 ) using a plurality of sector status bits ( 451 ) and forward/reverse skip flags ( 452, 453 ) stored in a sector identification record ( 45 ) of each sector to define a plurality of status indicators arranged sequentially to specify a plurality of sector configuration states for each memory sector, and to automatically bypass one or more dead sectors in the non-volatile memory array during forward copydown and reverse search operations.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention is directed in general to flash memories andmethods for operating same. In one aspect, the present invention relatesto a system and method of using flash memory to emulate ElectricallyErasable Programmable Read Only Memory (EEPROM).

2. Description of the Related Art

Electrically erasable, programmable, read-only memory (EEPROM) is a typeof non-volatile memory (NVM) used with microcontrollers,microprocessors, computers and other electronic devices (such asautomotive embedded controllers) to store data. EEPROM is typicallycharacterized by the ability to erase and write individual bytes ofmemory many times over, with programmed locations retaining their dataover an extended period when the power supply is removed. However,because of the increased cost and size requirements and manufacturingdifficulties for EEPROM memories, some devices emulate EEPROM memoryusing a portion of a sector or block of erasable flash memory to mirrorinformation stored in a RAM, so that the stored information ismaintained in flash memory when the device is not powered. However,there continue to be challenges with overcoming flash memory cycling andreliability that that can adversely affect the integrity of emulatedEEPROM data stored in the flash array, such as when power is unstable(referred to as “brownouts”) and asynchronous resets at the device cancause corruption of the mirrored information at the flash memory. Inaddition, flash memory latent defects may result in a flash operationfailure for a sector after extensive program and erase cycles prevent aprogram or erase error from being resolved, in which case the “dead”sector is declared as invalid and is dropped from the operational flow.While sector identification schemes for EEPROM emulation have beenproposed to use status bits interleaved with sector erasure operationsto enable the determination of start, stop and sector status within asystem, these schemes have been found to have weaknesses during updatesteps and do not provide the ability to track dead sectors in the flashmemory.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may be understood, and its numerous objects,features and advantages obtained, when the following detaileddescription is considered in conjunction with the following drawings, inwhich:

FIG. 1 is a schematic block diagram of a microcontroller architecturewhich implements an emulated EEPROM with a sector status identificationscheme for tracking dead sectors;

FIG. 2 is a table illustrating sector status classifications andassociated sector header codes which may be used to provide sectorstatus information and to mark one or more upcoming dead sectors inaccordance with selected embodiments of the present disclosure;

FIG. 3 is a block diagram illustrating a plurality of flash arraysectors in an EEPROM emulation scheme which uses sector identificationheader codes to skip a dead sector in both automated search and copydownsequences in accordance with selected embodiments of the presentdisclosure;

FIG. 4 is a block diagram of a plurality of flash array sectors in anEEPROM emulation scheme illustrating an example sequence for programmingsector identification header codes to skip a dead sector in bothautomated search and copydown sequences in accordance with selectedembodiments of the present disclosure;

FIG. 5 is a schematic block diagram of an address generation unit whichmay be used to generate a controlled address sequence for a flash arrayin an EEPROM emulation unit in accordance with selected embodiments ofthe present disclosure; and

FIG. 6 is a simplified schematic flow chart illustrating various methodsfor using a flash memory to perform EEPROM emulation in accordance withselected embodiments of the invention.

DETAILED DESCRIPTION

A method, system and apparatus are described for performing EEPROMemulation to store information at a non-volatile memory using a robustsector identification scheme to track dead sectors or blocks of recordsby storing a plurality of status bits for each sector programmingoperation along with a pair of offsets flags or markers at a sectoridentification header to allow for forward or reverse passage around adead sector. By interleaving sector program operations with theprogramming of a plurality of status bits in the sector identificationheader which define a plurality of status indicators arrangedsequentially to specify a plurality of sector configuration states forthe sector, a brownout or other corrupting event during a programoperation may be indicated by the failure to store one of the statusbits. And by storing each status indicator as a plurality of bits whichare logically combined (e.g., via an OR operation), the sector statedetection scheme is immune to program disturb or individual bit erasedefects. Brownout tolerance may also be promoted by defining uniquesector status update steps which align with the plurality of status bitsto sequentially track the lifecycle of a sector in an emulated EEPROMsystem. In selected embodiments, each sector's life progression ismarked by two distinct program operations to make them brownout tolerantand to track dead sectors during automated search and copy down routinesby programming each sector identification header with two offsets flagsto allow for forward or reverse passage through the sector and to warnof an impending encounter with a dead sector.

In this disclosure, an improved system, apparatus, and fabricationmethod are described for emulated EEPROM memory devices that addressvarious problems in the art where various limitations and disadvantagesof conventional solutions and technologies will become apparent to oneof skill in the art after reviewing the remainder of the presentapplication with reference to the drawings and detailed descriptionprovided herein. Various illustrative embodiments of the presentinvention will now be described in detail with reference to theaccompanying figures. While various details are set forth in thefollowing description, it will be appreciated that the present inventionmay be practiced without these specific details, and that numerousimplementation-specific decisions may be made to the invention describedherein to achieve the device designer's specific goals, such ascompliance with process technology or design-related constraints, whichwill vary from one implementation to another. While such a developmenteffort might be complex and time-consuming, it would nevertheless be aroutine undertaking for those of ordinary skill in the art having thebenefit of this disclosure. For example, selected aspects are shown inblock diagram form, rather than in detail, in order to avoid limiting orobscuring the present invention. Some portions of the detaileddescriptions provided herein are presented in terms of algorithms andinstructions that operate on data that is stored in a computer memory.Such descriptions and representations are used by those skilled in theart to describe and convey the substance of their work to others skilledin the art. In general, an algorithm refers to a self-consistentsequence of steps leading to a desired result, where a “step” refers toa manipulation of physical quantities which may, though need notnecessarily, take the form of electrical or magnetic signals capable ofbeing stored, transferred, combined, compared, and otherwisemanipulated. It is common usage to refer to these signals as bits,values, elements, symbols, characters, terms, numbers, or the like.These and similar terms may be associated with the appropriate physicalquantities and are merely convenient labels applied to these quantities.Unless specifically stated otherwise as apparent from the followingdiscussion, it is appreciated that, throughout the description,discussions using terms such as “processing” or “computing” or“calculating” or “determining” or “displaying” or the like, refer to theaction and processes of a computer system or similar electroniccomputing device, state machine, electronic circuit, logic, firmware,application specific integrated circuit (ASIC), or computing circuitryor module that manipulates and transforms data represented as physical(electronic) quantities within the computer system's registers andmemories into other data similarly represented as physical quantitieswithin the computer system memories or registers or other suchinformation storage, transmission or display devices.

FIG. 1 is a schematic block diagram of a data processing devicearchitecture 100 which includes an emulated EEPROM device 18 forproviding the non-volatile storage functionality of EEPROM memory whilemasking the restrictions and disadvantages of using non-volatile EEPROMmemory or flash memory as the sole memory storage. As depicted, theemulated EEPROM device 18 includes a volatile random access memory (RAM)20, memory controller 22, and flash array memory 24 connected andcontrolled by an EEPROM emulation unit 23 in the memory controller 22.As will be appreciated, the EEPROM emulation unit 23 may be implementedin whole or in part as a software driver in selected embodiments, andmay be implemented in whole or in part as hardware in other embodiments.In operation, the EEPROM emulation unit 23 implements a sector statusidentification scheme for tracking dead sectors in accordance withselected embodiments of the present disclosure. Implemented as software,hardware, firmware or any combination of the foregoing, the EEPROMemulation unit provides random memory access at RAM 20 in combinationwith emulated EEPROM functionalities with the flash array 24, such asorganizing data records, initializing and de-initializing EEPROM,reporting EEPROM status, and reading, writing, and deleting datarecords. In any software implementation, the software may be executed bya separate processor (e.g., 14) or by a processor or controller (notshown) in the emulated EEPROM device 18.

In the example shown in FIG. 1, the data processing device 100 may beimplemented as a microcontroller (e.g., an embedded automotivecontroller) which includes one or more CPU or processor cores 14 and anemulated EEPROM device 18 for programmably storing non-volatile data.The CPU(s) 14 and emulated EEPROM device 18 are connected together viaone or more busses or system interconnect(s) 12 to store data (e.g.,diagnostic data, adaptive control data, and/or security data) that iswritten frequently during the microcontroller lifetime, requiring a highprogram/erase endurance of many thousand cycles. To avoid the costs anddisadvantages associated with using conventional EEPROM memory to storenon-volatile data, the emulated EEPROM device 18 is provided toprogrammably store non-volatile data using a random access memory (RAM)20, a memory controller 22, and a non-volatile flash memory array 24 forstoring a plurality of flash memory blocks or sectors, each of whichincludes one or more EEPROM data records. In selected embodiments, flasharray 24 may be implemented as NAND flash, NOR flash, or another type ofnon-volatile memory. The data records stored in the flash memory array24 refer to a collection of data items or fields arranged for processingas if stored in an EEPROM, and may include a data record status field, adata record ID field, a data size field and one or more data fields. Thespecific arrangement of the EEPROM data record is prescribed by theapplication program that processes it, and may include both fixed-lengthand variable length records.

In the depicted emulated EEPROM device 18, the memory controller 22 isconnected to non-volatile flash array 24 via signal lines labeledADDRESS, DATA_IN, READ_DATA, STATUS, and CONTROL. Though not shown,memory controller 22 may be connected to random access memory (RAM) 20via similar signal lines. RAM 20 and memory controller 22 are alsoconnected to system interconnect 12. In addition, a reset signal may beprovided to CPU(s) 14 and memory controller 22. The reset signal may be,for example, a global reset signal for data processing device 100.Memory controller 22 includes an EEPROM emulation driver and/or hardwaremodule 23 having program code and/or circuitry for implementing thesector status identification scheme for tracking dead sectors. For thepurpose of illustration, emulated EEPROM device 18 is shown as adiscrete device, but the emulated EEPROM device 18 may be implemented asan integrated circuit that includes other components of data processingdevice 100, such as processor 14. As will be appreciated, the emulatedEEPROM device 18 may be implemented as a standalone flash module havingits own processing functionality or with microcontrollers,microprocessors, computers and other electronic devices which use flashmemory to emulate EEPROM memory.

In support of data access requests to the RAM 20, the memory controller22 is configured to store and retrieve information at flash array 24.Memory controller 22 can store information at flash array 24 byproviding an address via node ADDRESS, writing data via node DATA_IN,updating status information for a sector or record via node STATUS, andconfiguring control information at node CONTROL. Similarly, memorycontroller 22 can retrieve information stored at flash array 24 byproviding an address at node ADDRESS and configuring control informationat node CONTROL to perform a read operation at flash array 24 wherebythe information stored at the address is returned to control module 22via node READ_DATA and associated status information for thecorresponding sector or record is returned via node STATUS. Memorycontroller 22 can include a data processing device such as amicroprocessor, a microcontroller, logic devices, or a combinationthereof that is configured to administer the procedures associated withmemory controller 22.

During operation, processor 14 (or some other module or device withmemory access privileges) can communicate directly with RAM 20 viasystem interconnect 12 to store and retrieve information at RAM 20 viaan access request. In this setting, an access request to storeinformation at the RAM 20 is a “write access,” and an access request toretrieve information stored at the RAM 20 is a “read access.” Eachaccess request includes an access address corresponding to a location atRAM 20. In the case of a write access, the access request also includesdata information that is to be written to the provided address. Inresponse to a write access, RAM 20 stores the received write data at amemory location associated with the received write address. In responseto a read access, RAM 20 retrieves the data stored at the memorylocation indicated by the address and provides the data via systeminterconnect 12.

In the case of a write access, memory controller 22 will store the dataassociated with the write access at flash array 24. The data will thusbe preserved in the event of a power fluctuation (including a powerloss) or reset event at the data processing device 100. For example, ifthe memory controller 22 determines that data associated with a writerequest is different than the data stored at the memory location of theRAM 20 indicated by the address associated with the write request, thememory controller 22 may store both the address and the data associatedwith the write request as a record at the flash array 24. But if flasharray 24 cannot erase an individual record, the memory controller 22generates a new record for each write access that results inmodification of data stored at the RAM 20. As a result, there may be aplurality of records associated with a particular memory location of RAM20, in which case the most recently created record associated with aparticular memory address stores the most up-to-date or valid data forthat address, and any data associated with an address of RAM 20 that hasbeen replaced by newer data is referred is invalid.

In creating new records, the memory controller 22 operates a sequentialmanner whereby each new record is stored at a location logicallyadjacent and immediately following the location used to store the recordcreated in response to the preceding write access. As data is stored atRAM 20 and successive records corresponding to the updates are createdat flash array 24, the available space to store information at flasharray 24 is reduced. To provide sufficient storage space in the flashmemory for new records, the memory controller 22 may be configured todetermine when the amount of space available at flash array 24 is belowa defined or programmable threshold. When the threshold is reached, thememory controller 22 performs data consolidation and data erasure inselected sectors or blocks to ensure that there are empty locations thatare sequential to the most recently updated location and that areavailable to accommodate new records in response to data updates at RAM20. The process for managing flash sectors by successively creating newrecords, consolidating records, and erasing sectors is performed to makenew sectors available for storing data records in the flash array 24.

In FIG. 1, the process for managing the flash sectors in a non-volatileflash memory 24 in an emulated EEPROM device 18 is illustrated withreference to the plurality of flash memory blocks or sectors 30, 32, 34,36, and 38 (sectors 30-38) wherein a sector is logically contiguousportion of flash array 24 for storing one or more records. Flash array24 may also include an empty region 40, which includes one or more emptysectors. An empty sector refers to a sector where all locations allottedfor storing records are erased. The illustrated sectors 30-38 include anoldest sector 30 (the sector that was least-recently filled), an oldersector 32 (the sector that was filled after filling oldest sector 30),one or more newer filled sectors 34 (the sector(s) filled more recentlythan the older sector 32), a newest-filled sector 36 (the sector thatwas most recently filled), and a currently filling sector 38. Each ofthe filled sectors 30, 32, 34, and 36 includes no empty locations in thesense that all locations contain either a record or contain statusinformation associated with the sector, though it will be appreciatedthat a record in a filled sector may include empty space available tostore additional data for the address associated with the record.

The currently filling sector 38 is the sector which will store the nextor “new” record created in flash array 24. By way of illustration, thecurrently filling sector 38 may include a first location or record 45for storing sector identification header codes which may be used toprovide sector status information and to mark one or more upcoming deadsectors). The first location 45 may be a first sector header or recordwhich includes a first field 451 for storing a plurality of status bits,a second field 452 for storing a reverse skip or offset flag foravoiding one or more adjacent dead sectors in a reverse direction (aloneor in combination with an erase count), and a third field 453 forstoring a forward skip or offset flag for avoiding one or more adjacentdead sectors in a forward direction. The combination of fields 451-453may be referred to as a sector header for the currently filling sector38. As described hereinbelow, the plurality of status bits aresequentially written or programmed into the first field 451 so as to beinterleaved with separate programming operations so that any brownout orother corrupting event occurring between writing or programming of thestatus bits will likely result in a failure to store the latter statusbit(s) and thereby provide an indication of a failed programmingoperation.

The currently filling sector 38 may also include one or more secondlocations or records 46 in which are stored one or more records. Inaddition, the currently filling sector 38 may include a currentlyfilling location or record 48 which includes a status information field481, an address information field 482, and a data information field 483.Finally, the currently filling sector 38 may include one or more emptylocations 50 illustrated parenthetically to include “FFFF,”corresponding to the value of data present at locations included aterased sectors.

In an example programming operation for the currently filling sector 38,the memory controller 22 may use the currently filling sector 38 toperform data consolidation and data erasure in one or more sectors ofthe array 24 upon determining that the number of erased locations atflash array 24 available to store new records is below a threshold. Whenthis threshold is met, the memory controller 22 may perform aconsolidation operation by reviewing each record at oldest filled sector30 and then compressing and copying each valid record found therein tothe currently filling location or record 48 in the currently fillingsector 38. In particular, to copy a record, memory controller 22performs a write access to create a new record at currently-fillingsector 38 and writes the contents of the record being copied to the newrecord. Once memory controller 22 determines that all valid records havebeen copied from oldest filled sector 30 to currently filling sector 38,memory controller 22 performs an erase operation to erase oldest filledsector 30. Thus, the consolidation operation frees space for additionalrecords to be stored at flash array 24.

Each sector 30-38 in the flash memory 24 may include a sectoridentification location or record (e.g., 45) that may be used tofacilitate sector processing by storing sector status information alongwith offset flags to mark one or more upcoming dead sectors. In thisway, memory controller 22 can access the sector status informationassociated with a sector to identify how the sector is currently beingused. For example, the sector status information can be used to identifythat a particular sector is empty, erased, currently filling or full, orbeing used for another purpose, such as compressing or erasing anothersector. By interleaving the programming of status bits stored in thesector identification location/record, the emulated EEPROM device 18provides a robust status system that is brownout tolerant and moreimmune to single bit wear out mechanisms and disturb issues. This isachieved through using multiple physical bits allocated per status bitto define a comprehensive plurality of configuration state definitions.The emulated EEPROM device 18 may also process the offset flags in thesector identification location/record to manage the presence of deadsectors in the flash array 24 such that automated search algorithms canbe used.

Turning now to FIG. 2, there is illustrated a table 200 of sector statusclassifications and associated sector header codes which may be used toprovide sector status information and to mark one or more upcoming deadsectors in accordance with selected embodiments of the presentdisclosure. Table 200 includes a first column 210 containing sectorclassifications, a second column 212 containing example sector statusbits (in binary form) associated with each sector classification, and athird column 214 containing “OR-ed” groupings of the status bits fromthe second column 212. In selected embodiments, the memory controller 22is configured to update sector status bits in the sector headercorresponding to the second column 212 or to the third column 214 as thesector classification progresses through a sequence of programoperations. In embodiments where the status bits used to store recordsat flash array 24 can only be programmed to a “logic zero” level, thesector status bits used to identify the current classification of asector differ by how many status bits are programmed to a “logic zero”level. In an example embodiment illustrated in the second column 212 oftable 200, the sector status bits used to identify a sector statusincludes thirty (30) status bits which may be arranged as ten statusindicator groupings of three status bits each (e.g., FIRST SECTOR STATUSINDICATOR (2:0), SECOND SECTOR STATUS INDICATOR (5:3), . . . TENTHSECTOR STATUS INDICATOR (30:28). As will be appreciated, additional orfewer groupings of status bits may be include in the sector status bitsto identify additional or fewer status classifications. In this way,each of the groupings of three programmed status bits may be used todifferentiate each sector status, alone or in combination with otherinformation from the sector header code. In an example implementation,the sector status bits are contained in bit positions 90:61 of a sectoridentification header/record. Alternatively, the OR'ed sector statusbits are contained in bit positions 70:61 of a sector identificationheader/record.

While the arrangement and assignment of status bit groupings shown intable 200 shows the same logical values for the ERASED and READY (FIRSTPROGRAM) states, it will be appreciated that the status bits could bearranged and assigned so that each of the identified elevenconfiguration states has its own corresponding sector status bit(s). Forexample, the ERASED state could be assigned status bit configuration111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111, theREADY (FIRST PROGRAM) state could be assigned status bit configuration111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)000, theREADY state could be assigned status bit configuration111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)000_(—)000, andso on so that the COMPRESS state could be assigned status bitconfiguration000_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000.

As illustrated with the third column 214 of table 200, each sectorstatus indicator grouping of sector bits may be represented with acorresponding logical sector status bit by applying a logical “OR”operation to each grouping of sector bits. By representing each logicalsector status bit with three physical bits which are OR'ed together, thesector status information maintained at the emulated EEPROM device 18achieves improved immunity to program disturbances (e.g., brownout), andalso avoids problems arising from one of the status bits in a grouphaving an erase issue.

The table 200 includes additional sector header codes which may beincluded in each sector identification header or record which may beused to mark one or more upcoming dead sectors. For example, table 200includes a fourth column 216 containing example reverse skip codes oroffset flag values for bypassing a dead sector in the reverse searchdirection. The reverse skip codes or offset flag values may be stored asbinary or hexadecimal values to indicate the number of adjacent deadsectors to be skipped in a given direction (e.g., reverse direction). Inselected embodiments, each reverse skip code may be combined with anECOUNT (erase cycle count) value for the sector representing the numberof times the sector has been erased. Whether combined with the ECOUNTvalue or not, the reverse skip codes may be protected with errorcorrecting code (ECC) to detect and correct internal data corruption.

While the reverse skip codes can specify any desired number of deadsectors, in selected embodiments, the reverse skip codes are used tospecify a maximum of two (2) dead sectors that can be skipped in thereverse direction by using four bits with two bits assigned to eachskipped sector. In these embodiments, the reverse skip codes caneffectively specify 0, 1, and 2 values corresponding to “no skip,” skip1 sector,” and “skip 2 sectors” instructions. In the unlikely event ofthree or more dead sectors occurring back to back, the memory controller22 may be configured to reprogram the sector identificationheader/record to create an ECC double fault that will force softwareintervention. In an example implementation, the ECC-protected reverseskip codes and ECOUNT value are contained in bit positions 60:22 of asector identification header/record.

The table 200 also includes a fifth column 218 which contains exampleforward skip codes or offset flags for bypassing a dead sector in theforward copydown direction. By storing the forward skip codes or offsetflag values as binary or hexadecimal values, the number of adjacent deadsectors to be skipped in a given direction (e.g., forward direction) isindicated. In selected embodiments, the forward skip codes may beprotected with error correcting code (ECC) to detect and correctinternal data corruption. In selected embodiments, the forward skipcodes are used to specify a maximum of two (2) dead sectors that can beskipped in the reverse direction, though any desired number of deadsectors can be specified by the forward skip codes. By using four bitswith two bits assigned to each skipped sector, the forward skip codescan effectively specify 0, 1, and 2 values corresponding to “no skip,”skip 1 sector,” and “skip 2 sectors” instructions. In the unlikely eventof three or more dead sectors occurring back to back, the memorycontroller 22 may be configured to reprogram the sector identificationheader/record to create an ECC double fault that will force softwareintervention. In an example implementation, the ECC-protected forwardskip codes are contained in bit positions 21:0 of a sectoridentification header/record.

With the arrangement of sector status bits illustrated in the secondcolumn 212 of table 200, the memory controller 22 may be configured tointerleave distinct sector programming operations with the sequentialprogramming of first and second groups of status bits. For example,during a first programming operation (e.g., configuring a sector asREADY), a first group of status bits (e.g., FIRST SECTOR STATUSINDICATOR (2:0)) can be programmed, and during a subsequent programmingoperation (e.g., configuring a sector as FILLING (FIRST PROGRAM)), asecond group of status bits (e.g., SECOND SECTOR STATUS INDICATOR (5:3))can be programmed. This interleaved programming may be illustrated withreference to the rows 221-231 in the table 200.

In particular, a first row 221 in table 200 includes sectorclassification ERASED which may be represented as shown in the secondcolumn 212 with unprogrammed sector status bit values (e.g.,111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111) andreverse skip and ECOUNT values (e.g., FFFF_FF). As illustrated in thethird column 214, the logical OR combination of three bit groups fromthe sector status bit values generates OR'ed sector status bit values(e.g., 11_(—)1111_(—)1111) corresponding to the ERASED sector status. Inselected embodiments, the “logic one” values in the first set of sectorstatus bit values and the first reverse skip and ECOUNT value are theresult of a sector-erase operations, so memory controller 22 need notperform a separate program operation to store these values.

Row 222 in table 200 includes sector classification READY (FIRSTPROGRAM) which may be represented as shown in the second column 212 witha set of sector status bit values having “logic one” values and with theECOUNT value which has been incremented after the ERASE operation. Inthis way, the READY (FIRST PROGRAM) sector classification may bedifferentiated from the ERASED sector classification by the ECOUNT valuein the fourth column 216. As illustrated in the third column 214, thelogical OR combination of three bit groups from the sector status bitvalues generates OR'ed sector status bit values (e.g.,11_(—)1111_(—)1111) corresponding to this first program operation forthe READY sector status, and the fourth and fifth columns 216, 218contain the reverse and forward skip values (e.g., 0, 1, or 2)identifying adjacent dead sectors.

Row 223 in table 200 includes the sector classification READY (or EMPTY)which may be represented as shown in the second column 212 with a set ofsector status bit values (e.g.,111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)000) inwhich the least significant status bit or bit group (e.g., a three-bitgroup of status bits) are programmed to a “logic zero” level, therebydifferentiating the READY sector classification from the READY (FIRSTPROGRAM) sector classification. As illustrated in the third column 214,the logical OR combination of three bit groups from the sector statusbit values generates OR'ed sector status bit values (e.g.,11_(—)1111_(—)1110) corresponding to this second program operation forthe READY sector status, and the fourth and fifth columns 216, 218contain the reverse and forward skip values (e.g., 0, 1, or 2)identifying adjacent dead sectors. The READY sector classificationcorresponds to sectors at, for example, EMPTY REGION 40 of FIG. 1.

Row 224 in table 200 includes the sector classification FILLING (FIRSTPROGRAM) which may be represented as shown in the second column 212 witha set of sector status bit values (e.g.,111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)000_(—)000) inwhich the next least significant status bit or bit group (e.g., thefourth, fifth and sixth least significant status bits) are programmed toa “logic zero” level, thereby differentiating the FILLING (FIRSTPROGRAM) sector classification from the READY sector classification. Asillustrated in the third column 214, the logical OR combination of threebit groups from the sector status bit values generates OR'ed sectorstatus bit values (e.g., 11_(—)1111_(—)1100) corresponding to this firstprogram operation for the FILLING sector status, and the fourth andfifth columns 216, 218 contain the reverse and forward skip values(e.g., 0, 1, or 2) identifying adjacent dead sectors.

Row 225 in table 200 includes the sector classification FILLING (orFULL) which may be represented as shown in the second column 212 with aset of sector status bit values (e.g.,111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)000_(—)000_(—)000) inwhich the next least significant status bit or bit group (e.g., theseventh, eighth, and ninth least significant status bits) are programmedto a “logic zero” level, thereby differentiating the FILLING sectorclassification from the FILLING (FIRST PROGRAM) sector classification.As illustrated in the third column 214, the logical OR combination ofthree bit groups from the sector status bit values generates OR'edsector status bit values (e.g., 11_(—)1111_(—)1000) corresponding tothis second program operation for the FILLING sector status, and thefourth and fifth columns 216, 218 contain the reverse and forward skipvalues (e.g., 0, 1, or 2) identifying adjacent dead sectors. The FILLING(or FULL) sector classification corresponds to sectors at, for example,CURRENTLY FILLING 38 of FIG. 1, and the FULL sector classificationcorresponds to filled sectors 30, 32, 34, and 36 of FIG. 1. In selectedembodiments, additional status bits can be used to differentiate betweenthe FILLING sector and FULL sectors. In other embodiments, the FILLINGsector can be identified by memory controller 22 by searching backwardsfrom the first empty sector to locate the first sector having sectorstatus bitvalues=111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)000_(—)000_(—)000.

Row 226 in table 200 includes the sector classification PREVIOUS SECTORBEING ERASED which may be represented as shown in the second column 212with a set of sector status bit values (e.g.,111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)000_(—)000_(—)000_(—)000) inwhich the next least significant status bit or bit group (e.g., thetenth, eleventh, and twelfth least significant status bits) areprogrammed to a “logic zero” level, thereby differentiating the PREVIOUSSECTOR BEING ERASED sector classification from the FILLING sectorclassification. As illustrated in the third column 214, the logical ORcombination of three bit groups from the sector status bit valuesgenerates OR'ed sector status bit values (e.g., 11_(—)1111_(—)0000)corresponding to a previous sector, and the fourth and fifth columns216, 218 contain the reverse and forward skip values (e.g., 0, 1, or 2)identifying adjacent dead sectors.

Row 227 in table 200 includes the sector classification PREVIOUS SECTORQUALIFIED FOR ERASE which may be represented as shown in the secondcolumn 212 with a set of sector status bit values (e.g.,111_(—)111_(—)111_(—)111_(—)111_(—)000_(—)000_(—)000_(—)000_(—)000) inwhich the next least significant status bit or bit group (e.g., thethirteenth, fourteenth, and fifteenth least significant status bits) areprogrammed to a “logic zero” level, thereby differentiating the PREVIOUSSECTOR QUALIFIED FOR ERASE sector classification from the PREVIOUSSECTOR BEING ERASED sector classification. As illustrated in the thirdcolumn 214, the logical OR combination of three bit groups from thesector status bit values generates OR'ed sector status bit values (e.g.,11_(—)1110_(—)0000) corresponding to a second program operation forerasing the previous sector, and the fourth and fifth columns 216, 218contain the reverse and forward skip values (e.g., 0, 1, or 2)identifying adjacent dead sectors.

Row 228 in table 200 includes the sector classification PREVIOUS SECTORERASE COMPLETE which may be represented as shown in the second column212 with a set of sector status bit values (e.g.,111_(—)111_(—)111_(—)111_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000) inwhich the next least significant status bit or bit group (e.g., thesixteenth, seventeenth, and eighteenth least significant status bits)are programmed to a “logic zero” level, thereby differentiating thePREVIOUS SECTOR ERASE COMPLETE sector classification from the PREVIOUSSECTOR QUALIFIED FOR ERASE sector classification. As illustrated in thethird column 214, the logical OR combination of three bit groups fromthe sector status bit values generates OR'ed sector status bit values(e.g., 11_(—)1100_(—)0000) corresponding to a third program operationfor erasing the previous sector, and the fourth and fifth columns 216,218 contain the reverse and forward skip values (e.g., 0, 1, or 2)identifying adjacent dead sectors.

Row 229 in table 200 includes the sector classification ERASE COMPLETEDwhich may be represented as shown in the second column 212 with a set ofsector status bit values (e.g.,111_(—)111_(—)111_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000) inwhich the next least significant status bit or bit group (e.g., thenineteenth, twentieth, and twenty-first least significant status bits)are programmed to a “logic zero” level, thereby differentiating theERASE COMPLETED sector classification from the PREVIOUS SECTOR ERASECOMPLETE sector classification. As illustrated in the third column 214,the logical OR combination of three bit groups from the sector statusbit values generates OR'ed sector status bit values (e.g.,11_(—)1000_(—)0000) corresponding to a fourth program operation forerasing the previous sector, and the fourth and fifth columns 216, 218contain the reverse and forward skip values (e.g., 0, 1, or 2)identifying adjacent dead sectors. The ERASE COMPLETED sectorclassification is stored at the FULL sector that was filled immediatelyafter filling the oldest filled sector. For example, when erasing oldestfilled sector 30 at FIG. 1, the older filled sector 32 of FIG. 1 is usedto store sector status bitvalues=111_(—)111_(—)111_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000.

Row 230 in table 200 includes the sector classification COMPRESS (FIRSTPROGRAM) which may be represented as shown in the second column 212 witha set of sector status bit values (e.g.,111_(—)111_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000) inwhich the next least significant status bit or bit group (e.g., thetwenty-second, twenty-third, and twenty-fourth least significant statusbits) are programmed to a “logic zero” level, thereby differentiatingthe COMPRESS (FIRST PROGRAM) sector classification from the ERASECOMPLETED sector classification. As illustrated in the third column 214,the logical OR combination of three bit groups from the sector statusbit values generates OR'ed sector status bit values (e.g.,11_(—)0000_(—)0000) corresponding to this first program operation forthe COMPRESS sector status, and the fourth and fifth columns 216, 218contain the reverse and forward skip values (e.g., 0, 1, or 2)identifying adjacent dead sectors.

Row 231 in table 200 includes the sector classification COMPRESS whichmay be represented as shown in the second column 212 with a set ofsector status bit values (e.g.,111_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000) inwhich the next least significant status bit or bit group (e.g., thetwenty-fifth, twenty-sixth, and twenty-seventh least significant statusbits) are programmed to a “logic zero” level, thereby differentiatingthe COMPRESS sector classification from the COMPRESS (FIRST PROGRAM)classification. As illustrated in the third column 214, the logical ORcombination of three bit groups from the sector status bit valuesgenerates OR'ed sector status bit values (e.g., 10_(—)0000_(—)0000)corresponding to this second program operation for the COMPRESS sectorstatus, and the fourth and fifth columns 216, 218 contain the reverseand forward skip values (e.g., 0, 1, or 2) identifying adjacent deadsectors. Note that, before a sector becomes an oldest filled sector anda candidate for being compressed and subsequently erased, it will havebeen an older filled sector, and have received sector status bitvalues=111_(—)111_(—)111_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000at the time that a previous oldest filled sector was being erased.

As described hereinabove, the sector header codes may be sequentiallyprogrammed to track the lifecycle progression of each sector statusclassification which proceeds with multiple distinct program operations,thereby providing the ability to detect and respond to potentialbrownouts or other corrupting events. For example, the sector statusbits may be used, alone or in combination with an ECOUNT value, todetect potential brownout events that occur as an ERASED sector isconfigured as READY. In an example illustrated in FIG. 2, by programmingthe ECOUNT value and first grouping of three status bits (e.g., FIRSTSECTOR STATUS INDICATOR (2:0) in a sequential manner, these sectorheader codes indicate that the READY (FIRST PROGRAM) and READY programoperations have occurred to configure a given sector. But if the memorycontroller 22 retrieves sector header codes indicating that the ECOUNTvalue was programmed and that the first grouping of bits was notprogrammed, then this signals to the memory controller 22 that abrownout event may have occurred before the second program operation forthe READY sector status program operation. This may occur if a brownoutoccurred while programming the status bits at the FIRST SECTOR STATUSINDICATOR (2:0), in which case the memory controller 22 classifies thatsector as a newly erased sector and once again programs the status bitsat the FIRST SECTOR STATUS INDICATOR (2:0) to identify the newly erasedsector as an empty or READY sector.

In addition or in the alternative, the sequential programming of thesector status bits or bit groups (from least significant to moresignificant) allows each lifecycle progression of sector statusclassification to be implemented with two distinct program operationswhich can be tracked to detect potential brownouts or other corruptingevents. For example, by programming the second and third groupings ofthree status bits (e.g., SECOND SECTOR STATUS INDICATOR (5:3) and THIRDSECTOR STATUS INDICATOR (8:6)) in a sequential manner, the sector statusbits indicate that the FILLING (FIRST PROGRAM) and FILLING programoperations have occurred to configure a given sector. But if the memorycontroller 22 retrieves sector status bits from the sectoridentification header/record wherein the second grouping of bits wasprogrammed but not the third grouping of bits (e.g.,111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)000_(—)000),then this signals to the memory controller 22 that a brownout event mayhave occurred before the second program operation for the FILLING sectorstatus program operation. This may occur if a brownout occurred whileprogramming the status bits at the THIRD SECTOR STATUS INDICATOR (8:6),in which case the memory controller 22 concludes that the sector is anempty sector, and again programs the status bits at the SECOND SECTORSTATUS INDICATOR (5:3) and THIRD SECTOR STATUS INDICATOR (8:6) toclassify the sector as a currently filling sector.

Likewise, if the fourth and fifth groupings of three status bits (e.g.,FOURTH SECTOR STATUS INDICATOR (11:9) and FIFTH SECTOR STATUS INDICATOR(14:12)) are sequentially programmed to indicate that the PREVIOUSSECTOR BEING ERASED and PREVIOUS SECTOR QUALIFIED ERASE programoperations have occurred, any retrieval of sector status bits whereinthe fourth (but not the fifth) grouping of bits was programmed (e.g.,111_(—)111_(—)111_(—)111_(—)111_(—)111_(—)000_(—)000_(—)000_(—)000),this signals that a brownout event may have occurred before the PREVIOUSSECTOR QUALIFIED ERASE program operation. This may occur if a brownoutoccurred while programming the status bits at the FIFTH SECTOR STATUSINDICATOR (14:12), in which case the memory controller 22 concludes thatthe sector is a filling sector, and again programs the status bits atthe FOURTH SECTOR STATUS INDICATOR (11:9) and FIFTH SECTOR STATUSINDICATOR (14:12) to classify the sector to indicate that the previoussector is qualified for erase.

In similar fashion, if the sixth and seventh groupings of three statusbits (e.g., SIXTH SECTOR STATUS INDICATOR (17:15) and SEVENTH SECTORSTATUS INDICATOR (20:18)) are sequentially programmed to indicate thatthe PREVIOUS SECTOR ERASED COMPLETE and ERASE COMPLETED programoperations have occurred, any retrieval of sector status bits whereinthe sixth (but not the seventh) grouping of bits was programmed (e.g.,111_(—)111_(—)111_(—)111_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000),this signals that a brownout event may have occurred before the ERASECOMPLETED program operation. This may occur if a brownout occurred whileprogramming the status bits at the SEVENTH SECTOR STATUS INDICATOR(20:18), in which case the memory controller 22 concludes that thesector is PREVIOUS SECTOR QUALIFIED FOR ERASE, and again programs thestatus bits at the SIXTH SECTOR STATUS INDICATOR (17:15) and SEVENTHSECTOR STATUS INDICATOR (20:18) to classify the sector to indicate theerase operation is completed.

Finally, if the eighth and ninth groupings of three status bits (e.g.,EIGHTH SECTOR STATUS INDICATOR (23:21) and NINTH SECTOR STATUS INDICATOR(26:24)) are sequentially programmed to indicate that the COMPRESS(FIRST PROGRAM) and COMPRESS program operations have occurred, anyretrieval of sector status bits wherein the eighth (but not the ninth)grouping of bits was programmed (e.g.,111_(—)111_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000_(—)000),this signals that a brownout event may have occurred before the COMPRESSprogram operation. This may occur if a brownout occurred whileprogramming the status bits at the NINTH SECTOR STATUS INDICATOR(26:24), in which case the memory controller 22 concludes that thesector erase operation is complete, and again programs the status bitsat the EIGHTH SECTOR STATUS INDICATOR (23:21) and NINTH SECTOR STATUSINDICATOR (26:24) to classify the sector to indicate the compressionoperation is completed.

As described herein, the sector identification status bits may be usedby the memory controller 22 to define unique sector status update stepswhich align with the lifecycle of a sector in an emulated EEPROM system.To accomplish this, each sector's classification progression (e.g., fromERASED to READY) is marked by two distinct program operations to makethem brownout tolerant. A failure to program on the first step isallowed if it can successfully be qualified by the second programoperation. By using two program steps for every new sectorclassification progression, brownout issues can be detected and avoided.

As will be appreciated, one or more sectors or blocks of records mayhave a program or erase error that cannot be resolved during theemulated EEPROM operations. In such cases, the failed sector is declaredinvalid and is dropped from the emulated EEPROM operations so thatsubsequent passes through the flash memory array automatically skip thissector automatically. This is known as a dropped or dead sector. To skipover dead sectors, selected embodiments of the present disclosureprovide a sector identification scheme having the capability to automatetracking of dead sectors within the system. To this end, each sectoridentification header/record stores one or more offsets flags whichallow for forward or reverse passage through the sector and will warn ofan impending encounter with a dead sector.

Referring now to FIG. 3, there is shown a block diagram 300 of aplurality of flash array sectors 310, 320, 330, 340 in an EEPROMemulation scheme which uses sector identification header codes (e.g.,312-314) to skip a dead sector in both automated search and copydownsequences in accordance with selected embodiments of the presentdisclosure. In the first sector 310 (Sector 0), the header codes includea status bits field 312 for storing sector identification status bitsidentifying the status (e.g., ERASED, FILLED, etc.) for that sector, areverse skip field 313 for specifying the presence of any upcoming deadsectors to be skipped during reverse passage through the sectors, aforward skip field 314 for specifying the presence of any upcoming deadsectors to be skipped during forward passage through the sectors, andadditional locations 311 for storing records for the first sector 310.The other flash array sectors 320, 330, 340 are similarly organized withstatus bits fields (e.g., 332, 342), reverse skip fields (e.g., 333,343), forward skip fields (e.g., 334, 344), and additional record fields(e.g., 331, 341), except for any dead sector (e.g., 320) where thevarious fields are indicated with the “don't care” value X.

In the depicted example, an erase failure at the second sector 320(Sector 1) causes the second sector to be treated as a dead sector. Toavoid the dead sector 320 (Sector 1), the sector identificationlocation/record 332-334 for the third sector 330 (Sector 2) isprogrammed to store a reverse skip code value RSKIP=1 at the reverseoffset flag field 333, thereby instructing any reverse search sequence361 to skip 335 a single sector after processing the current sector 330(Sector 2), thereby avoiding the dead sector 320 (Sector 1) andproceeding directly to the next functioning sector 310 (Sector 0). Toavoid the dead sector 320 (Sector 1) from the opposite or copydowndirection, the sector identification location/record 312-314 for thefirst sector 310 (Sector 0) is programmed to store a forward skip codevalue FSKIP=1 at the forward offset flag field 314, thereby instructingany forward copydown sequence 362 to skip 315 a single sector afterprocessing the first sector 310 (Sector 0), thereby avoiding the deadsector 320 (Sector 1) and proceeding directly to the next functioningsector 330 (Sector 2). In similar fashion, the remaining sectoridentification header codes are programmed to provide reverse skip codevalues RSKIP=0 and forward skip code values FSKIP=0 to indicate thatthere is no adjacent dead sector so that reverse search and forwardcopydown sequences can proceed directly to the next adjacent sector.

To identify the number of sectors to be skipped, the reverse and forwardskip fields may include a plurality of bits (e.g., 2) assigned to eachsector skipped. For example, if a maximum of two sectors can be skippedin the reverse direction and two bits are assigned to each sectorskipped, then RSKIP=1111 would indicate that no sector skipping isrequired (or RSKIP=0). Likewise, RSKIP=1100 would indicate that oneadjacent sector should be skipped (or RSKIP=1), and RSKIP=0000 wouldindicate that two adjacent sectors should be skipped (or RSKIP=2).

To avoid the computational cost, complexity and delay from storing deadsector location information for retrieval and reference and processingby firmware, selected embodiments of the present disclosure program thereverse and forward skip codes or offset flag values directly in thesector header codes to enable automated sequence pass through of sectorsfrom oldest to newest for copydown and in reverse for record searchoperations. To illustrate an example sequence for programming sectoridentification header codes, reference is now made to FIG. 4 where thereis shown a block diagram 400 of a plurality of flash array sectors 410,420, 430, 440 in an EEPROM emulation scheme over the course of time(e.g., t=1 through t=n+1). In the example flash array, each sector 410,420, 430, 440 is organized with STATUS fields, reverse skip (RSKP)fields, forward skip (FSKP) fields, and additional record fields withtheir program status indicated (e.g., READY, COMPRESS, RECORDS FILLED,etc.).

At a first time interval (t=1), the flash array includes a first sector410 (Sector 0) that is READY and a fourth sector 440 (Sector 3) that isFILLED. In addition and as indicated at 401, the sector records 421 atthe second sector 420 (Sector 1) fail to erase, while the third sector430 (Sector 2) includes a (previously programmed) STATUS field code(e.g., 11_(—)1111_(—)0000) indicating that the previous sector (e.g.,Sector 1) is being erased. At this point in time, the STATUS and FSKPfields in the sectors 410 are programmed in the initial states tospecify the respective status codes, along with skip or offset flagvalues RSKIP=0, FSKIP=0 indicating that no sectors are skipped.

At a second time interval (t=2), a forward skip is added to the sectoridentification location/record (sector ID) for the first sector 410(Sector 0) if the following sector fails to erase (as indicated at 401).At this point, the status of the second and fourth sectors 420, 440remain unchanged. However, the third sector 430 (Sector 2) includes aSTATUS field 432 (e.g., 10_(—)0000_(—)0000) indicating that the records431 in the third sector 430 are being compressed. In addition and asindicated at 402, a marker is placed in the sector identificationlocation/record (sector ID) for the first sector 410 (Sector 0) to flagthe upcoming DEAD sector 422 in the forward copydown direction. Inparticular, the forward skip field 411 in the first sector 410 isprogrammed to instructing any forward copydown sequence 412 to skip onesector (FSKP=1) after processing the first sector 410 (Sector 0),thereby avoiding the dead sector 420 (Sector 1) and proceeding directlyto the next functioning sector 430 (Sector 2). Otherwise, the STATUS,RSKP, and FSKP fields in the sectors 410, 420, 430, 440 remainunchanged.

At a third, subsequent time interval (t=n), a new sector subsequent tothe dead sector passes an ERASE change (as indicated at 403). At thispoint, the status of the first and second sectors 410, 420 remainunchanged. However, the sector records 433 at the third sector 430(Sector 2) are now ERASED, and the fourth sector 440 (Sector 3) includesa STATUS field 441 (e.g., 11_(—)1100_(—)0000) indicating that theprevious sector (Sector 2) erase is complete. Otherwise, the STATUS,RSKP, and FSKP fields in the sectors 410, 420, 430, 440 remainunchanged.

At a fourth time interval (t=n+1), a reverse skip (and optional ECOUNTvalue) are added to the sector identification location/record (sectorID) for the third sector 420 (Sector 2) after a successful eraseoperation (as indicated at 403). At this point, the status fields of thesecond and fourth sectors 420, 440 remain unchanged. However, the sectorrecords 435 at the third sector 430 (Sector 2) are now READY, and thethird sector 430 (Sector 2) includes a STATUS field 436 (e.g.,11_(—)1111_(—)1110) indicating that the records 435 in the third sector430 are READY. In addition and as indicated at 404, a marker is placedin the sector identification location/record (sector ID) for the thirdsector 430 (Sector 2) to flag the upcoming DEAD sector 423 in thereverse search direction. In particular, the reverse skip field 437 isprogrammed in the third sector 430 to instructing any reverse searchsequence 438 to skip one sector (RSKP=1) after processing the thirdsector 430 (Sector 1), thereby avoiding the dead sector 420 (Sector 1)and proceeding directly to the next functioning sector 410 (Sector 0).Otherwise, the STATUS, RSKP, and FSKP fields in the sectors 410, 420,430, 440 remain unchanged.

Turning now to FIG. 5, there is shown a schematic block diagram 500 ofan address generation unit 506 and associated control modules 502, 504which may be used to generate a controlled address sequence for a flasharray 508 in an EEPROM emulation unit in accordance with selectedembodiments of the present disclosure. In selected embodiments, theaddress generation unit and associated control modules may beimplemented in the memory controller of the emulated EEPROM device assoftware, hardware, firmware or any combination of the foregoing toprovide the flash memory 508 with a controlled address sequence 507 forfully automating the search and copydown operations with programmedforward and reverse skip instructions to avoid dead sectors withoutrequiring time consuming software interrupt routines to process deadsectors. Though not explicitly shown, the flash memory 508 stores aplurality of records arranged into sectors, each of which includes asector identification location/record (sector ID) in which sectorclassification status codes and reverse and forward skip values havebeen programmed. As the records 509 are read out of the flash memory508, the Sector ID Decode module 502 uses the associated AGU addressreceived from the Address Generation Unit 506 to decode the records toidentify any sector identification location/record (sector ID), and toextract therefrom the programmed reverse and forward skip values RSKP,FSKP. The extracted RSKP and FSKP values are provided as Skip Backwardand Skip Forward skip sector count values to the Dead SectorIdentification module 504, thereby indicating the number of sectors toskip in either the reverse or forward directions, respectively. To guidethe computations at the Dead Sector Identification module 504, theAddress Generation Unit 506 provides a Forward or Reverse indication(For/Rev) to the Dead Sector Identification module 504 to indicatewhether the Address Generation Unit 506 is in forward copydown orreverse search mode. With these inputs, the Dead Sector Identificationmodule 504 generates a sector size adjustment signal (Delta+/−SectorSize) by converting the sector skip counts into address adjustmentvalues that are fed to the Address Generation Unit 506. Using the sectorsize adjustment signal, the Address Generation Unit 506 may beconfigured to generate a controlled address sequence 507 forautomatically avoiding dead sectors during search and copydownoperations at the flash memory 508.

To illustrate an example EEPROM emulation methodology for providingautomated search and copydown operations with the disclosed sectoridentification header codes, reference is now made to FIG. 6 which showsa simplified schematic flow chart 600 illustrating various methods forprogramming reverse and forward skip values in accordance with selectedembodiments of the invention. In the depicted methodology, the processbegins at step 601 during forward copydown processing of an array offlash sectors as an erase operation is applied to a selected sector. Ifthe sector erase operation fails (FAIL outcome to decision 602), theprocess programs the FSKIP value in the previous qualified sector with ajump value to the next qualified (e.g., non-dead) sector which is to beprocessed for compression. As the compression of the next qualifiedsector proceeds, the next qualified sector has its STATUS fieldprogrammed to indicate a COMPRESS status (at step 606) and thecompression operation is performed on the records in the next qualifiedsector (at step 608).

At some subsequent point, an erase operation is performed on the nextqualified sector. This can occur during a reverse search operation.Until such an erase operation occurs, the processing of the nextqualified sector is on hold (negative outcome to decision 610). However,when an erase operation is undertaken on the next qualified sector(affirmative outcome to decision 610), the process returns to step 602to evaluate the success of the erase operation. If the erase of the nextqualified sector also fails, the process steps 604, 606, 608 arerepeated as necessary or up until a specified limit, thereby updatingthe programmed FSKIP value to avoid the failed or dead sectors. However,if the sector erase operation succeeds (PASS outcome to decision 602),then the erased sector has its STATUS field programmed with the READYstatus at step 612. In addition, the processing at step 612 programs theRSKIP value in the erased sector with a jump value to the next qualified(e.g., non-dead) sector which is to be processed. In selectedembodiments, an ECOUNT value may be included in the programming of theRSKIP value in the erased sector. Once the FSKIP and RSKIP values areprogrammed in the sectors adjacent to one or more dead sectors, the deadsector(s) are eliminated from the EEPROM emulation processing. Afterstep 612, the process waits until an erase operation is applied to thenext sector (step 610), at which time the process returns to step 602.

By now it should be appreciated that there is provided herein a methodand apparatus for emulating EEPROM memory in non-volatile or flashmemory. In the disclosed methodology and system, a sector identificationrecord for a first non-volatile memory sector is programmed by storing afirst status indicator in the sector identification record uponperforming a first program operation on the first non-volatile memorysector. Subsequently, the sector identification record for the firstnon-volatile memory sector is programmed by storing a second statusindicator in the sector identification record as part of a plurality ofsector status bits upon performing a second program operation on thefirst non-volatile memory sector. In selected embodiments, the sectoridentification record may be programmed with the first status indicatorby storing a first plurality of status bits in the plurality of sectorstatus bits upon performing the first program operation, and may beprogrammed with the second status indicator by storing a secondplurality of status bits in the plurality of sector status bits uponperforming the second program operation, where the second plurality ofstatus bits are stored adjacent to the first plurality of status bitsand in more significant bit positions in the plurality of sector statusbits. In the sector identification record, the plurality of sectorstatus bits define a plurality of status indicators arrangedsequentially to specify a plurality of sector configuration states forthe first non-volatile memory sector, where the first and second programoperations are required to change a sector configuration state for thefirst non-volatile memory sector. With this arrangement, a possiblesector corrupting event associated with the first and second programoperations may be detected upon determining that the sectoridentification record includes the first status indicator but not thesecond status indicator. In embodiments where the first and secondprogram operations are, respectively, a READY FIRST program operationand a READY COMPLETE program operation, the first and second statusindicators are, respectively, an ERASE COUNT value and a first group ofleast significant status bits stored in the plurality of sector statusbit. In embodiments where the first and second program operations are,respectively, a FILLING FIRST program operation and a FILLING COMPLETEprogram operation, the first and second status indicators are,respectively, a first group of less significant status bits stored inthe plurality of sector status bits and a second, adjacent group of moresignificant status bits stored in the plurality of sector status bits.In embodiments where the first and second program operations are,respectively, a PREVIOUS SECTOR BEING ERASED program operation and aPREVIOUS SECTOR QUALIFIED FOR ERASE program operation, the first andsecond status indicators are, respectively, a first group of lesssignificant status bits stored in the plurality of sector status bitsand a second, adjacent group of more significant status bits stored inthe plurality of sector status bits. In embodiments where the first andsecond program operations are, respectively, a PREVIOUS SECTOR ERASECOMPLETE program operation and a ERASE COMPLETED program operation, thefirst and second status indicators are, respectively, a first group ofless significant status bits stored in the plurality of sector statusbits and a second, adjacent group of more significant status bits storedin the plurality of sector status bits. In embodiments where the firstand second program operations are, respectively, a COMPRESS FIRSTprogram operation and a COMPRESS COMPLETE program operation, the firstand second status indicators are, respectively, a first group of lesssignificant status bits stored in the plurality of sector status bitsand a second, adjacent group of more significant status bits stored inthe plurality of sector status bits. While programming the sectoridentification record with the first and second status indicators, itmay be determined that the first non-volatile memory sector has failedto erase, in which case a sector identification record for a previousnon-volatile memory sector that is adjacent to the first non-volatilememory sector may be programmed by storing a forward skip indicator inthe sector identification record for the previous non-volatile memorysector to automatically bypass the first non-volatile memory sectorduring a forward copydown sequence. In addition or in the alternative,upon determining that a subsequent non-volatile memory sector adjacentto the first non-volatile memory sector is successfully erased, thesector identification record for the subsequent non-volatile memorysector may be programmed by storing a reverse skip indicator in thesector identification record for the subsequent non-volatile memorysector to automatically bypass the first non-volatile memory sectorduring a reverse search sequence.

In another form, there is provided an emulated EEPROM system whichincludes a volatile RAM, a non-volatile memory, and a control module.The volatile RAM is used to store and access data via one or more accessrequests. The non-volatile memory includes a plurality of sectors forstoring records of the data stored in the volatile random access memory,where each sector includes a corresponding sector header for storing aplurality of sector status bits defining a plurality of statusindicators arranged to sequentially specify a lifecycle sequence ofsector configuration states for said sector. For example, the pluralityof status bits may include a first plurality of status bits forprogramming a first status indicator upon performing a first programoperation, and a second plurality of status bits for programming asecond status indicator upon performing a second program operation,where the second plurality of status bits are stored adjacent to thefirst plurality of status bits and in more significant bit positions inthe plurality of sector status bits. The sector header may also store aforward skip indicator for one or more adjacent dead sectors in thenon-volatile memory which may be used to automatically bypass the one ormore adjacent dead sectors during a forward copydown sequence, and/or areverse skip indicator for one or more adjacent dead sectors in thenon-volatile memory which may be used to automatically bypass the one ormore adjacent dead sectors during a reverse search sequence. Moregenerally, the sector header may store a sector skip indicator for oneor more adjacent dead sectors in the non-volatile memory which may beused to automatically bypass the one or more adjacent dead sectorsduring automated search or copydown operations. In selected embodiments,the non-volatile memory may be implemented with NAND or NOR flash memoryarray for storing a plurality of flash memory sectors, each of whichincludes one or more EEPROM data records and a corresponding sectorheader record. The control module is coupled to the non-volatile memoryand the volatile RAM, and is operable to program the plurality of sectorstatus bits in the sector header of each sector with first and secondprogram operations to change a sector configuration state for thesector. In selected embodiments, the control module includes an addressgeneration unit for generating a controlled address sequence based on asector size adjustment signal derived from the sector skip indicator inthe sector header.

In yet another form, there is provided an emulated electrically erasableprogrammable read-only memory (EEEPROM) device and associated method ofoperation. As disclosed, the EEPROM device includes an emulation memoryhaving a plurality of sectors for sequentially storing information in aplurality of records, where each sector includes (1) a sectoridentification record for storing a plurality of sector status bitsdefining a plurality of status indicators arranged to sequentiallyspecify a lifecycle sequence of sector configuration states for saidsector, (2) a forward skip indicator for one or more adjacent deadsectors in the emulation memory which may be used to automaticallybypass the one or more adjacent dead sectors during a forward copydownsequence, and (3) a reverse skip indicator for one or more adjacent deadsectors in the emulation memory which may be used to automaticallybypass the one or more adjacent dead sectors during a reverse searchsequence. The EEEPROM device also includes a memory controller coupledto the emulation memory, where the memory controller is operable toprogram the plurality of sector status bits in the sector identificationrecord of each sector with first and second program operations to changea sector configuration state for the sector. In selected embodiments,the emulation memory may be implemented as a NAND or NOR flash memoryfor storing a plurality of flash memory sectors, each of which includesone or more EEPROM data records and a corresponding sectoridentification record.

Although the described exemplary embodiments disclosed herein aredirected to a method and apparatus for detecting brownout events andautomatically eliminating dead sector processing during search andcopydown operations, the present invention is not necessarily limited tothe example embodiments which illustrate inventive aspects of thepresent invention that are applicable to a wide variety of EEPROMemulation schemes. In addition, selected embodiments may be implementedwith other memory systems, such as dynamic random-access memory (DRAM),static random-access memory (SRAM), magnetoresistive random-accessmemory (MRAM), or phase-change random access memory (PCRAM), or harddrive memory systems. Thus, the particular embodiments disclosed aboveare illustrative only and should not be taken as limitations upon thepresent invention, as the invention may be modified and practiced indifferent but equivalent manners apparent to those skilled in the arthaving the benefit of the teachings herein. Accordingly, the foregoingdescription is not intended to limit the invention to the particularform set forth, but on the contrary, is intended to cover suchalternatives, modifications and equivalents as may be included withinthe spirit and scope of the invention as defined by the appended claimsso that those skilled in the art should understand that they can makevarious changes, substitutions and alterations without departing fromthe spirit and scope of the invention in its broadest form.

Benefits, other advantages, and solutions to problems have beendescribed above with regard to specific embodiments. However, thebenefits, advantages, solutions to problems, and any element(s) that maycause any benefit, advantage, or solution to occur or become morepronounced are not to be construed as a critical, required, or essentialfeature or element of any or all the claims. As used herein, the terms“comprises,” “comprising,” or any other variation thereof, are intendedto cover a non-exclusive inclusion, such that a process, method,article, or apparatus that comprises a list of elements does not includeonly those elements but may include other elements not expressly listedor inherent to such process, method, article, or apparatus.

What is claimed is:
 1. A method of emulating EEPROM memory innon-volatile memory, comprising: programming a sector identificationrecord for a first non-volatile memory sector by storing a first statusindicator in the sector identification record upon performing a firstprogram operation on the first non-volatile memory sector; andprogramming the sector identification record for the first non-volatilememory sector by storing a second status indicator in the sectoridentification record as part of a plurality of sector status bits uponperforming a second program operation on the first non-volatile memorysector, where the plurality of sector status bits are defined by aplurality of status indicators arranged sequentially to specify aplurality of sector configuration states for the first non-volatilememory sector, and where the first and second program operations arerequired to change a sector configuration state for the firstnon-volatile memory sector.
 2. The method of claim 1 further comprisingdetecting a possible sector corrupting event associated with the firstand second program operations upon determining that the sectoridentification record includes the first status indicator but not thesecond status indicator.
 3. The method of claim 1 where storing thefirst status indicator comprises storing a first plurality of statusbits in the plurality of sector status bits upon performing the firstprogram operation, and where storing the second status indicatorcomprises storing a second plurality of status bits in the plurality ofsector status bits upon performing the second program operation, wherethe second plurality of status bits are stored adjacent to the firstplurality of status bits and in more significant bit positions in theplurality of sector status bits.
 4. The method of claim 1 where thefirst and second program operations comprise, respectively, a READYFIRST program operation and a READY COMPLETE program operation, andwhere the first and second status indicators comprise, respectively, anERASE COUNT value and a first group of least significant status bitsstored in the plurality of sector status bits.
 5. The method of claim 1where the first and second program operations comprise, respectively, aFILLING FIRST program operation and a FILLING COMPLETE programoperation, and where the first and second status indicators comprise,respectively, a first group of less significant status bits stored inthe plurality of sector status bits and a second, adjacent group of moresignificant status bits stored in the plurality of sector status bits.6. The method of claim 1 where the first and second program operationscomprise, respectively, a PREVIOUS SECTOR BEING ERASED program operationand a PREVIOUS SECTOR QUALIFIED FOR ERASE program operation, and wherethe first and second status indicators comprise, respectively, a firstgroup of less significant status bits stored in the plurality of sectorstatus bits and a second, adjacent group of more significant status bitsstored in the plurality of sector status bits.
 7. The method of claim 1where the first and second program operations comprise, respectively, aPREVIOUS SECTOR ERASE COMPLETE program operation and a ERASE COMPLETEDprogram operation, and where the first and second status indicatorscomprise, respectively, a first group of less significant status bitsstored in the plurality of sector status bits and a second, adjacentgroup of more significant status bits stored in the plurality of sectorstatus bits.
 8. The method of claim 1 where the first and second programoperations comprise, respectively, a COMPRESS FIRST program operationand a COMPRESS COMPLETE program operation, and where the first andsecond status indicators comprise, respectively, a first group of lesssignificant status bits stored in the plurality of sector status bitsand a second, adjacent group of more significant status bits stored inthe plurality of sector status bits.
 9. The method of claim 1, furthercomprising: determining that the first non-volatile memory sector hasfailed to erase; and programming a sector identification record for aprevious non-volatile memory sector that is adjacent to the firstnon-volatile memory sector by storing a forward skip indicator in thesector identification record for the previous non-volatile memory sectorto automatically bypass the first non-volatile memory sector during aforward copydown sequence.
 10. The method of claim 9, furthercomprising: determining that a subsequent non-volatile memory sectoradjacent to the first non-volatile memory sector is successfully erased;and programming a sector identification record for the subsequentnon-volatile memory sector by storing a reverse skip indicator in thesector identification record for the subsequent non-volatile memorysector to automatically bypass the first non-volatile memory sectorduring a reverse search sequence.
 11. An emulated EEPROM systemcomprising: a volatile random access memory for storing and accessingdata via one or more access requests; a non-volatile memory comprising aplurality of sectors for storing records of the data stored in thevolatile random access memory, each sector of the plurality of sectorscomprising a corresponding sector header for storing a plurality ofsector status bits defining a plurality of status indicators arranged tosequentially specify a lifecycle sequence of sector configuration statesfor said sector; and a control module coupled to the non-volatile memoryand the volatile memory, where the control module is operable to programthe plurality of sector status bits in the sector header of each sectorwith first and second program operations to change a sectorconfiguration state for the sector.
 12. The emulated EEPROM system ofclaim 11, where the non-volatile memory comprises a flash memory forstoring a plurality of flash memory sectors, each of which includes oneor more EEPROM data records and a corresponding sector header record.13. The emulated EEPROM system of claim 12, where flash memory comprisesa NAND flash array or a NOR flash array.
 14. The emulated EEPROM systemof claim 11, where the plurality of status bits comprises: a firstplurality of status bits for programming a first status indicator uponperforming a first program operation, and a second plurality of statusbits for programming a second status indicator upon performing a secondprogram operation, where the second plurality of status bits are storedadjacent to the first plurality of status bits and in more significantbit positions in the plurality of sector status bits.
 15. The emulatedEEPROM system of claim 11, where each sector header further comprises aforward skip indicator location for one or more adjacent dead sectors inthe non-volatile memory for storing a forward skip indicator which maybe used to automatically bypass the one or more adjacent dead sectorsduring a forward copydown sequence.
 16. The emulated EEPROM system ofclaim 11, where each sector header further comprises a reverse skipindicator location for one or more adjacent dead sectors in thenon-volatile memory for storing a reverse skip indicator which may beused to automatically bypass the one or more adjacent dead sectorsduring a reverse search sequence.
 17. The emulated EEPROM system ofclaim 11, where each sector header further comprises a sector skipindicator location for one or more adjacent dead sectors in thenon-volatile memory for storing a sector skip indicator which may beused to automatically bypass the one or more adjacent dead sectorsduring automated search or copydown operations.
 18. The emulated EEPROMsystem of claim 17, where the control module comprises an addressgeneration unit for generating a controlled address sequence based on asector size adjustment signal derived from the sector skip indicator inthe sector header.
 19. An emulated electrically erasable programmableread-only memory (EEEPROM) device, comprising: an emulation memoryhaving a plurality of sectors for sequentially storing information in aplurality of records, each sector comprising: a sector identificationrecord location for storing a plurality of sector status bits defining aplurality of status indicators arranged to sequentially specify alifecycle sequence of sector configuration states for said sector, aforward skip indicator location for one or more adjacent dead sectors inthe emulation memory which may be used to automatically bypass the oneor more adjacent dead sectors during a forward copydown sequence, and areverse skip indicator location for one or more adjacent dead sectors inthe emulation memory which may be used to automatically bypass the oneor more adjacent dead sectors during a reverse search sequence; and amemory controller coupled to the emulation memory, where the memorycontroller is operable to program the plurality of sector status bits inthe sector identification record of each sector with first and secondprogram operations to change a sector configuration state for thesector.
 20. The EEEPROM device of claim 19, where the emulation memorycomprises a flash memory for storing a plurality of flash memorysectors, each of which includes one or more EEPROM data records and acorresponding sector identification record.